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ABSTRACT 

The  following  paper  traces  the  history  of  product  data  exchange  standards  from  the  physical  model  through 
electronic  representations  such  as  IGES.  This  paper  provides  an  understanding  of  the  early  efforts  leading  to  ISO 
10303 — STandard  for  the  Exchange  of  Product  model  data  (STEP),  but  does  not  cover  STEP’S  development. 

1.  INTRODUCTION 

“Before  the  dawn  of  the  industrial  revolution,  engineering  work  was  defined  by  a physical  model 
of  a product  to  be  reproduced.  For  example,  a worker  manufacturing  a rifle  barrel  would  ensure 
that  the  dimensions  of  the  barrel  corresponded  to  a model  barrel  by  using  calipers  to  transfer 
measurements  from  one  to  the  other.  This  method  reinforced  the  concept  of  workers 
manufacturing  specific  product  types  rather  than  generic  components  of  larger  products. 

In  1801,  Gaspard  Monge  wrote  “La  Geometrie  Descriptive”  as  the  first  treatise  on  modem 
engineering  drawings.  This  included  the  theory  of  projecting  views  of  an  object  onto  three  planes 
and  the  addition  of  size  specifications  to  the  shape  descriptions.  With  the  mechanical  drawing,  an 
objective  standard  of  performance  for  workmanship  was  possible  and  thus  the  model  could  be 
eliminated.  The  drawing  enabled  the  practice  of  designing  a product  with  interchangeable  parts  to 
be  created.  Operations  could  then  be  performed  using  contractors  that  could  manufacture  different 
pieces  to  be  assembled.  This  capability  led  to  the  fragmentation  of  the  manufacturing  process  that 
exists  to  this  day. 

The  mechanical  drawing  concept  has  lasted  for  almost  200  years.  As  described  above,  the 
manufacturing  process  for  developing  quality  products  was  interwoven  with  the  method  for 
describing  the  products.  The  drawing  became  the  output  of  the  design  process  and  the  input  into 
the  manufacturing  process.  Drawings  were  converted  into  process  plans,  which  were  converted 
into  programs  or  procedures  for  the  manufacturing  operations.  Thus,  every  process  has  its  own 
view  of  the  product  data.  These  dissimilar  views  have  made  it  difficult  to  feed  back  knowledge 
about  different  processes  to  the  designer.  In  today’s  industrial  enterprises,  the  lifecycle  processes 
for  a product  are  no  longer  all  performed  by  the  same  group  of  people.  In  fact,  the  processes  are 
distributed  through  a network  of  factories. 

As  we  move  into  the  twenty-first  century,  new  manufacturing  technologies  are  needed  to  improve 
productivity  and  competitiveness.  In  this  information  and  computer  age.  companies  exchange  and 
share  information  across  the  country.  This  capability  is  needed  for  manufacturing  the  complex 
products  such  as  automobiles,  airplanes,  ships,  and  buildings  that  are  produced  today.  There  is  a 
special  consideration  for  accelerating  this  information  exchange  process  since  the  existing 
products  and  technologies  are  often  replaced  before  their  useful  life  has  expired  as  manufacturers 
compete  in  the  marketplace.  To  meet  production  deadlines,  computer-aided  design  tools  are  used 
to  move  products  from  concept,  through  design,  prototype,  manufacture,  test  and.  ultimately  the 
support  that  is  required  by  the  customer.”[l  ] 

Representing  product  data  has  evolved  slowly  over  these  same  200  years  (see  Figure  1).  Before  the  year  eighteen 
hundred,  a tangible  physical  model  of  a product  defined  product  descriptions.  The  invention  of  engineering 
drawings  in  the  early  1800’s  led  to  more  precise  product  descriptions.  This  increased  productivity'  many  fold  over 
using  a physical  model  to  define  a product. 


Figure  1.  Evolution  of  Product  Definition  Capabilities,  PDES,  Inc. 

Drawings  created  within  Computer-Aided  Design  (CAD)  tools  represented  a tremendous  productivity  gain  over 
paper  drawings,  such  as  ease  to  revise  and  archive.  CAD  tools  also  opened  new  opportunities,  such  as  enabling 
manufacturing  instructions  to  be  automatically  derived  and  executed  directly  from  the  drawing.  Nevertheless,  as 
computer  design  and  manufacturing  tools  proliferate,  so  do  the  formats  each  tool  uses  to  capture  and  store  product 
data.  While  paper  drawings  can  be  marked  up  by  anyone  with  a pencil,  a product  model  that  can  not  be  interpreted 
by  the  needed  CAD  tool  is  useless.  For  organizations  to  share  designs  that  must  be  interpretable  across  various 
CAD  and  Computer-Aided  Manufacturing  (CAM)  tools,  they  must  be  formatted  in  a manner  that  the  tools  can 
recognize.  This  requirement  is  becoming  increasingly  important  in  an  age  where  large  manufacturers  often  form 
joint  ventures  to  address  a business  opportunity,  and  where  partners  in  a supply  chain  are  being  called  upon  to 
deliver  an  increasingly  complex  array  of  services.  Most  companies  find  it  difficult  to  enforce  the  use  of  a common 
set  of  CAD/CAM  tools  within  their  organization,  much  less  across  (multiple)  supply  chains  and  among  joint  venture 
partners.  This  need  for  an  efficient  means  for  multiple  applications  to  share  engineering  data  has  driven  the 
development  of  a standard  for  a neutral  intermediate  format.  Such  an  approach  allows  a manufacturer  to  avoid 
developing  and  maintaining  several  system-specific  interfaces,  as  shown  in  Figure  2,  and  enables  applications  and 
equipment  to  be  driven  directly  from  a shared  file. 
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Efficiency  of  a Neutral  Format  for  Data  Exchange 


Finallay  Publications,  UK 


2.  EARLY  STANDARDS  DEVELOPMENT  EFFORTS 

The  tools  and  strategies  for  creating  a common  information  exchange  language  emerged  from  a variety  of  industry, 
academic,  and  government  efforts — both  national  and  abroad.  For  example,  in  the  1 970’s  the  X3/SPARC 
Committee  of  the  American  National  Standards  Institute  (ANSI)  contributed  the  notion  that  data  should  be  described 
in  a manner  that  was  independent  from  particular  uses  or  computer  technologies.  This  committee  proposed  a three- 
schema  methodology  with  which  one  basic  conceptual  information  model  could  be  realized  in  a variety  of  computer 
technologies,  and  presented  to  users  through  a variety  of  filters.  These  different  views  of  the  same  information  were 
called  conceptual,  internal,  and  external  views,  as  shown  in  Figure  3 [2] [3] [4], 
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ANSI/SPARC  Three-Laver  Architecture 


External  Views 


t t t 

Conceptual  View 
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Internal  View 


External  Layer 


Conceptual  or  Logical  Layer 


Physical  or  Internal  Layer 


Figure  3.  Adapted  from  Fowler,  Julian.  “STEP  for  Data  Management  Exchange  and  Sharing,” 

Technology  Appraisals  Ltd.,  Great  Britain,  1995. 

The  U.S.  Air  Force  built  upon  the  ANSI/X3/SPARC  methodology  by  developing  formal  methods  for  information 
modeling,  as  a result  of  their  Integrated  Computer  Aided  Manufacturing  (ICAM)  program.  The  intent  of  ICAM  was 
to  develop  new  manufacturing  automation  technologies,  which  could  lower  the  overall  cost  of  procurements.  It  was 
determined  that  new  systems  engineering  methodologies  were  needed  for  developing  new  technologies,  which 
implied  new  methods  of  defining  requirements.  This  work  resulted  in  a suite  of  formal  methodologies:  IDEFO  for 
modeling  activities;  IDEF1  (later  extended  to  IDEF1X)  for  modeling  information;  and  IDEF2  for  modeling  system 
dynamics  [5].  ICAM  then  awarded  a series  of  specific  contracts  that  required  the  use  of  these  new  systems 
engineering  methodologies.  The  Integrated  Programs  for  Aerospace-Vehicle  Design  (IPAD),  for  example,  had  a 
geometry  focus,  and  is  credited  as  being  the  first  to  make  use  of  information  modeling  for  systems  integration  [6]. 

ICAM,  and  its  subsequent  contracts  including  the  Product  Definition  Data  Interface  (PDDI)  and  Geometric 
Modeling  Application  (GMAP)  programs,  contributed  much  to  the  tools  and  methodologies  later  applied  in 
subsequent  standards.  Other  efforts  contributed  to  the  formal  description  of  the  information  needed  to  be  shared 
among  CAD  systems.  The  Computer-Aided  Manufacturing  - International  Inc.  (CAM-I)  organization,  through  the 
Geometric  Modeling  Project  that  it  began  in  the  early  1970's,  contributed  significantly  to  the  formal  description  of 
Boundary  Representation  (B-REP)  data.  The  result  of  the  CAM-I  funded  work,  which  was  a mathematical 
representation  of  standard  geometry  and  topology,  was  considered  ahead  of  its  time  and  clearly  captured  more 
information  than  the  ty  pical  CAD  systems  of  the  day  could  interpret.  It  was  submitted  to  ANSI  committee  Y 14.26 
(Computer  Aided  Preparation  of  Product  Definition  Data)  for  standardization.  The  CAM-I  specification  did  not 
contain  an  exchange  mechanism,  but  a foundational  description  of  that  data  which  could  be  exchanged  [7]. 


2.1  THE  BIRTH  OF  IGES  [8]  [9] 

In  1979  events  took  place  that  catalyzed  the  CAD  vendor  and  user  community  to  create  the  first  national  standard 
for  CAD  data  exchange.  Mechanical  CAD  systems  were  less  than  ten  years  old.  and  there  were  only  a handful  of 
products  with  any  significant  market  penetration.  Even  at  this  early  stage,  users  were  overwhelmed  by  the  inability 
to  share  data  among  these  tools  and  with  their  own  internally-developed  databases.  Frustration  was  evident  at  a 
fateful  two-day  Society  of  Manufacturing  Engineers  (SME)  meeting  in  the  Fall  of  1979.  On  the  first  day,  an 
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attendee  from  General  Electric  (GE)  challenged  a panel  of  CAD  vendors,  that  included  ComputerVision,  Applicon 
and  Gerber,  to  work  together  to  enable  a common  neutral  exchange  mechanism.  While  this  need  was  intuitive  from 
a user  perspective,  this  was  a very  threatening  proposition  to  the  CAD  vendors — who  feared  that  publicly  sharing 
the  structures  of  their  databases  would  be  tantamount  to  giving  away  their  competitive  advantage.  It  would  have 
been  easy  to  gloss  over  the  challenge;  after  all,  the  major  vendors  all  had  at  least  token  representation  on  the  ANSI 
committee  responsible  for  CAD  standards.  Instead,  the  ComputerVision  representative  responded  with  a challenge 
of  his  own:  If  Boeing  and  General  Electric  (and  perhaps  others)  would  contribute  the  CAD  translators  they  had 
already  developed,  the  vendors  would  share  their  database  structures. 

What  led  to  this  offer  was  a fortunate  blend  of  business  motivation  and  private  agendas.  It  just  so  happened  that  the 
evening  before  the  CAD  panel,  a CAD  vendor  representative  was  busily  recruiting  employees  for  his  (unannounced) 
new  robotics  company.  In  forming  this  company,  he  gained  the  user’s  perspective:  his  product  was  going  to  need  to 
have  access  to  CAD  data!  If  he  could  set  the  wheels  in  motion  for  the  CAD  vendors  to  make  public  their  database 
structures,  his  new  company  would  have  a better  chance  at  success;  however,  an  exchange  standard  was  also  in  the 
CAD  vendors’  best  interest.  The  CAD  vendors  tried  to  differentiate  themselves  based  on  loyalty  to  their  customers, 
that  also  had  the  negative  effect  of  dividing  the  end  users  into  camps.  There  were  large  Navy  contracts  looming  on 
the  horizon,  and  no  vendor  wanted  to  look  unresponsive  to  customer  requirements. 

In  the  evening  after  the  panel,  several  interested  parties  gathered  in  a smoke-filled  room  and  asked  themselves  if  a 
common  translator  was  really  possible.  The  room  had  the  right  combination  of  people  at  the  right  time.  This 
included  an  Air  Force  ICAM  representative  willing  to  fund  such  an  effort  and  a National  Bureau  of  Standards 
(NBS)1  representative  who,  after  a call  to  his  boss  at  home  for  a sleepy  approval,  was  willing  to  champion  it.  This 
whole  initiative  was  thus  initiated  with  a $50,000  contract  that  established  the  effort's  initial  structure  and 
requirements  [10]: 

• An  NBS  representative  was  placed  in  the  lead2; 

• Two  initial  IGES  committees  were  formed:  the  Steering  Committee  to  manage  the  effort  and  a Working 
Committee  to  perform  technical  work; 

• A draft  was  to  be  delivered  within  three  months. 

With  the  fundamentals  decided,  conversation  turned  to  a name  for  this  new  translation  project.  The  group  nixed  the 
suggestion  “Universal  Translator”  to  avoid  offending  those  within  ANSI,  who  might  have  interpreted  the  project  as 
a way  to  displace  the  years  of  effort  already  put  towards  a Y 14.26  standard.  A minimalist  approach  was  suggested: 

I Interim,  to  suggest  that  it  would  not  replace  ANSI’s  work; 

G Graphics,  not  geometry',  to  acknowledge  that  academics  may  come  up  with  superior  mathematical 
descriptions; 

E Exchange,  to  suggest  that  it  would  not  dictate  how  vendors  must  implement  their  internal  database;  and 

S Specification,  not  to  be  as  imposing  as  a standard. 

The  panel  reported  on  the  second  day,  and  the  wheels  were  set  in  motion  to  create  an  “IGES.”  Once  the  panel 
admitted  that  a common  translation  mechanism  was  possible,  it  was  impossible  to  stop  the  momentum  of  the 
customers’  enthusiasm  and  expectations.  Applicon  and  ComputerVision  agreed  to  open  up  their  internal  databases, 
GE  offered  its  neutral  database,  and  Boeing  offered  the  structure  of  its  Computer  Integrated  Information  Network 
(CUN)  database.  Both  GE  and  Boeing  contributed  their  existing  translators.  A core  team  was  formed  that  included 
representatives  from  NBS,  Boeing,  and  GE.  Team  members  had  worked  closely  with  each  of  the  vendors  on 
internal  integration  projects.  This  prior  experience  built  the  expertise  and  trust  needed  to  craft  a solution  in  a very 
short  time,  and  neither  vendor  felt  it  gave  an  unfair  advantage  to  the  other. 

Soon  after,  an  open  meeting  was  held  at  the  National  Academy  of  Sciences  on  October  10,  1979.  Approximately 
200  people  attended  to  herald  the  birth  of  IGES.  There  was  an  atmosphere  of  extraordinary  excitement,  although 
not  everyone  was  supportive.  In  addition,  although  it  was  hotly  debated,  the  name  of  this  project  was  eventually 
accepted  with  the  minor  change  from  “Interim"  Graphics  Exchange  Specification  to  “Initial”  Graphics  Exchange 
Specification. 


1 Department  of  Commerce’s  National  Bureau  of  Standards  was  later  renamed  the  National  Institute  of  Standards 
and  Technology  (NIST). 

2 Roger  Nagel  of  NBS,  Walt  Braithwaite  of  Boeing  and  Philip  Kennicott  of  GE  formed  the  initial  IGES  team. 
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After  two  critical  reviews,  the  IGES  team  released  its  first  draft  in  January  1980,  containing  geometry,  graphical 
data,  and  annotations.  IGES  was  submitted  to  the  ANSI  Y 14.26'  committee  for  standardization,  which  forced  the 
committee  to  try  to  reconcile  the  very  different  views  embodied  by  the  IGES  work  and  the  work  funded  by  CAM-1 
on  boundary  representation  description.  When  version  one  of  IGES  was  standardized  (Y14.26M-1981* 4),  the  work 
funded  by  CAM-I  was  attached  but  unintegrated  with  the  remainder  of  the  standard.  This  work  was  contained  in  the 
section  entitled  “Section  5 - Basic  shape  description.”  Future  versions  of  the  IGES  standard  omitted  this  fifth 
section. 

2.2  PRODUCT  DEFINITION  DATA  INTERFACE  (PDDI) 

IGES  provided  a very  practical  first  solution  for  CAD  data  exchange,  complete  with  an  exchange  file  format.  It  was 
remarkable  in  the  speed  with  which  it  was  developed,  due  in  part  to  the  relatively  limited  scope,  the  small  size  of  the 
committee  working  on  it,  and  a commitment  to  produce  a draft  within  three  months.  Once  it  fell  under  the  scrutiny 
of  an  ever-broadening  community,  weaknesses  were  identified  that  eventually  justified  embarking  on  a new  standard 
that  could  break  tradition  with  IGES.  The  Air  Force  ICAM  program  again  made  a significant  contribution  to  the 
evolution  of  product  data  exchange  standards,  this  time  through  its  Product  Definition  Data  Interface  (PDDI) 
contract.  The  purpose  of  PDDI  was  to  develop  a mechanism  to  allow  the  complete  exchange  or  sharing  of  product 
model  data  directly  among  computer  applications — without  human  intervention.  PDDI  with  its  geometry  focus, 
developed  a set  of  information  models,  a modeling  language  that  contributed  to  EXPRESS  [11],  an  exchange  file 
format  that  separates  the  data  being  exchanged  from  its  definition,  and  a mechanism  for  applications  to  share  data. 

One  of  the  tasks  of  this  contract  involved  an  evaluation  of  IGES  in  the  context  of  its  current  implementations.  This 
resulted  in  a thorough  report  [12]  and  numerous  constructive  requests  for  changes  to  IGES.  This  evaluation  activity 
helped  the  community  clearly  define  IGES's  shortcomings: 

• Flavorings.  IGES  contained  several  ways  to  capture  the  same  information,  which  made  proper  interpretation 
largely  dependent  on  the  particular  “flavor”  of  the  pre-  and  post-processors. 

• File  size/processing  time.  IGES  was  heavily  criticized  for  requiring  large  files  that  took  hours  or  even  days  to 
parse,  given  the  average  computing  power  available  at  the  time. 

• Loss  of  information  during  exchange.  Information  would  inevitably  be  lost  when  information  is  passed 
between  two  CAD  systems  with  inherently  different  capabilities. 

• Lack  of  discipline,  architecture.  There  was  a perception  that  IGES  was  developed  without  rigorous  technical 
discipline,  and  that  the  use  of  information  modeling  would  be  useful. 

• Upward  compatibility.  The  need  for  generations  of  processors  to  parse  files  compliant  with  earlier  versions  of 
IGES  thwarted  the  breadth  and  rate  of  change  in  succeeding  versions. 

• Automated,  rather  than  improved  upon,  paper  system.  IGES  was  seen  as  a method  to  exchange  engineering 
drawings,  but  not  capable  of  capturing  complete  product  data  (including  administrative  information)  to  enable 
more  sophisticated  automation. 

Although  PDDI  was  a research  exercise,  it  contributed  understanding,  mechanisms,  and  models  to  future  standards, 
most  notably  ISO  10303 — Standard  for  the  Exchange  of  Product  Model  Data  (STEP). 

Additional  shortcomings  were  later  identified  in  a paper  by  Peter  Wilson: 

• Subsetting.  Vendors  selected  and  implemented  only  portions  of  the  whole  of  IGES,  thus  making  exchange 
between  two  systems  impossible  without  prior  agreement  on  what  was  to  be  exchanged. 

• Conformance  testing.  There  was  no  mechanism  for  testing  processors  or  resolving  errors  between  two 
processors  [13]. 


2.3  SUBSETS  AND  APPLICATION  PROTOCOLS 

The  use  of  formalized  subsets  of  IGES  entities  offered  one  approach  to  improving  the  quality  and  predictability  of 
translations.  NBS,  under  sponsorship  from  the  U.S.  Department  of  Defense  Computer-Aided  Acquisition  and 
Lifecycle  Support  (CALS)  program,  led  the  development  of  IGES  subsets.  The  U.S.  Department  of  Defense 
eventually  stipulated  IGES  subsets  for  various  application  areas,  such  as  technical  illustrations  and 
electrical/electronic  applications,  within  their  CALS  suite  of  military  standards.  Subsets  allowed  IGES  processors  to 
be  classified  by  the  functionality  that  they  could  support  entirely , and  acted  as  a predefined  written  agreement 


' ANSI  Y14.26  committee  name  is  Digital  Representation  for  Communication  of  Product  Definition  Data. 

4 Since  revised  and  republished  as  ANSI/US  PRO/IPO  100. 
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• 

between  a sending  and  receiving  party.  The  IGES  community  quickly  learned  that  merely  specifying  subsets  of 
entities  was  insufficient— accurate  exchange  required  additional  instructions  for  mapping  CAD  system  data  to  the 
specified  IGES  entities.  STEP’S  concept  of  application  protocols  (APs)  and  Conformance  Classes  grew  from  the 
lessons  learned  regarding  IGES  entity  subsets  and  the  early  work  done  by  NIST  for  the  U.S.  Navy  on  the  IGES 
Architecture,  Engineering,  and  Construction  (AEC)  application  protocol. 

The  first  demonstration  IGES  AP  was  the  Department  of  Energy  Data  Exchange  Format  (DOEDEF),  which  was 
developed  by  the  design  and  production  agencies  of  the  nuclear  weapons  complex  in  1985.  The  DOEDEF  AP 
specified  a subset  of  IGES  entities  with  instructions  on  data  translation,  and  a few  “user-defined”  entities  for  data 
specific  to  weapons  systems.  Software  was  developed  at  Sandia  for  translating  individual  CAD  IGES  data  into  and 
out  of  DOEDEF,  and  the  complete  system  was  demonstrated  in  March  1986.  The  first  standard  IGES  AP  was  the 
IGES  3D  Piping  AP,  developed  in  large  part  through  work  on  the  Navy  Navy/Industry  Digital  Data  Exchange 
Standards  Committee  (NIDDESC)  contract. 

3.  INTERNATIONAL  PLAYERS 

Several  international  efforts  also  contributed  to  the  evolution  of  data  exchange  standards. 

3.1  AECMA  REPORT  OF  GEOMETRY  DATA  EXCHANGE  STUDY  GROUP 

In  1977,  the  European  aerospace  industry  recognized  a major  problem  in  exchanging  shape  representation  on 
collaborative  projects.  The  European  Association  of  Aerospace  Industries  (AECMA)  developed  a common 
exchange  format,  based  on  a simple  surface  type,  that  allowed  the  collaborating  companies  to  exchange  surface 
geometry.  The  format  was  used  on  a few  occasions,  but  the  advent  of  more  complex  surface  types,  integrated  into 
vendor  systems,  caused  it  to  fall  into  disuse  [14].  Even  so,  there  was  good  work  done  by  AECMA.  The  United 
Kingdom  contributed  the  AECMA  Report  of  the  Geometry  Data  Exchange  Study  Group  to  the  International 
Organization  for  Standardization  (ISO)  effort  for  building  an  international  product  model  data  standard  [15]. 

3.2  FLACHENSCHNITTSTELLE  DES  VERBANDES  DER  DEUTSCHEN 
AUTOMOBILINDUSTRIE  (VDA-FS  AND  VDA-IS) 

The  Germans  standardized  Flachenschnittstelle  des  Verbandes  der  deutschen  Automobilindustrie  (VDA-FS),  which 
addressed  the  exchange  of  free  form  surfaces  and  free  form  curves  needed  by  the  automotive  industry.  VDA-FS 
offered  a competing  exchange  file  format  to  that  of  IGES.  The  VDA  was  created  in  1982  to  increase  the  efficiency 
of  the  design  process  and  usefulness  of  CAD/CAM  systems.  The  Germans  brought  VDA-FS  to  the  international 
table  to  contribute  toward  the  international  product  model  data  standardization  effort  [16]. 

The  German  automotive  industry,  through  VDA-IS  (IS-IGES  Subset),  defined  subsets  of  annotation  entities  relevant 
for  various  applications  in  automobile  manufacturing.  These  subsets  were  created  so  that  compliance  could  be 
tested.  The  particular  data  exchange  requirements  met  by  these  subsets  included:  drawing  information,  two-  and 
three-dimensional  geometry,  and  analytic  and  free  form  surfaces  [17], 

3.3  STANDARD  D’ECHANGE  ET  DE  TRANSFERT  (SET) 

The  French  Standard  d'Echange  et  de  Transfert  (SET)  project  started  at  Aerospatiale  in  1983.  Designed  to  address 
the  difficulties  using  IGES,  the  primary  industrial  drivers  of  SET  were  automotive  and  aerospace  industries.  The 
SET  standard  represents  the  results  of  the  requirement  to  exchange  data  between  different  CAD/CAM  systems,  and 
from  the  need  to  archive  these  data.  Version  1.1  of  SET  was  put  on  the  international  table  to  contribute  toward  the 
STEP  activity.  It  contained: 

• Detailed  specifications  for  the  mechanical  area, 

• Supplementary  information  about  the  data  structures  and  concepts  employed,  and 

• Rules  and  recommendations  concerning  specifications  to  ensure  coherence  in  future  developments  [18]. 

Association  GOSET  is  an  organization  established  by  industry  and  government  in  France  to  support  continued 
development  and  maintenance  of  SET.  GOSET  representatives  have  also  been  active  contributors  to  ISO  10303  and 
STEP  conformance  testing  services  [19], 
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4.  THE  PDES  INITIATION  EFFORT 

By  1984,  many  of  these  international  efforts  had  produced  enough  results  to  be  compared,  and  an  international 
community  was  preparing  to  form  in  hopes  of  creating  a common  solution  to  CAD  data  exchange.  The  drivers  for  a 
common  international  standard  included: 

• Global  commerce  and  data  exchange; 

• Increasingly  complex  products; 

• Multi-use  software,  e.g.,  design  or  engineering  systems  that  apply  to  multiple  industries  and  applications; 

• Reliance  on  suppliers  at  all  phases  of  product  development; 

• Need  for  lifecycle  support. 

Many  felt  that  IGES  could  not  adequately  respond  to  these  pressures. 

In  May  of  1984,  a late  night  meeting  of  the  IGES  Organization  Edit  Committee  was  held.  The  outcome:  the  Boeing 
representative  was  tasked  to  write  a paper  on  what  the  next  generation  of  IGES  might  look  like  without  the 
constraint  of  providing  upward  compatibility  for  IGES  processors.  This  informal  request  was  in  response  to 
pressures  from  the  PDDI  results  and  European  efforts.  The  first  Product  Data  Exchange  Specification  (PDES) 
report  was  issued  in  July  of  1984,  and  was  followed  by  a second  report  in  November  of  1984.  These  reports  laid  the 
groundwork  for  the  PDES  Initiation  Effort,  which,  similar  to  PDDI,  was  considered  a theoretical  exercise  at  building 
a standard  based  on  a broader  automation  goal  and  the  discipline  of  information  modeling.  The  PDES  Initiation 
Effort  used  a simple  machined  part  as  a product  emulator,  and  focused  on  both  the  logical  information  being 
captured  and  the  “physical”  mechanisms  of  data  exchange.  Those  involved  originally  assumed  that  this  next- 
generation  standard  would  be  IGES  Version  3.  Instead,  the  work  spawned  a separate  U.S.  national  effort  known  as 
PDES  [20].  PDES  was  eventually  folded  into  the  international  effort  led  by  ISO  TC184/SC4  responsible  for 
developing  and  standardizing  STEP. 

The  PDES  Initiation  Task  and  Report  also  included  an  Electrical  Schematic  Reference  Model.  The  Initiation  Task 
validated,  through  modeling,  the  concept  that  electrical  connectivity  and  mechanical  joining  both  shared  a common 
underlying  topology.  This  topological  foundation  found  later  application  in  electrical  product  modeling  for  both 
IGES  and  STEP. 

5.  HOW  DID  ELECTRICAL  CONTENT  FIND  ITS  WAY  INTO  AN  ISO 

STANDARD^]? 

One  might  wonder  how  electrical  content  ended  up  in  ISO,  rather  than  an  International  Electrotechnical  Commission 
(IEC)  standard.  As  with  STEP,  the  roots  trace  back  to  IGES.  The  original  vision  for  IGES  included  easy  access  to 
all  machine  readable  product  data  from  any  CAD  tool,  including  data  about  electrical  and  electronic  products.  In 
1981,  more  than  a dozen  extensions  were  proposed  so  that  electronic  uses  of  general-purpose  CAD  systems  could  be 
accommodated.  These  extensions  reached  consensus  in  May  of  1982  for  inclusion  in  Version  2.0.  Electrical 
connectivity,  however,  proved  difficult  to  implement  as  originally  defined  in  IGES.  Under  the  leadership  of  the 
IGES  Organization  Electrical  Applications  Subcommittee  (EAS)\  developers  began  using  information  modeling  in 
1983  to  improve  the  quality  of  electrical  constructs.  Revised  extensions  for  connectivity  were  approved  in  July 
1984,  and  included  in  IGES  3.0.  The  EAS  had  tested  the  extensions  (and  the  information  models)  through  a 
functional  circuit  board  designed  in  Minneapolis  and  sent  as  an  IGES  file  to  Albuquerque  where  two  hundred 
undrilled  copies  of  the  board  were  manufactured.  A few  years  later,  a few  boards  with  plated  through  holes  were 
manufactured  from  the  old  IGES  file.  Two  of  the  boards  were  sent  to  NIST  where  parts  were  assembled  onto  it,  and 
the  assembly’s  functionality  verified. 

Apart  from  the  quality  of  the  constructs,  the  EAS  was  concerned  about  overlap  and  duplication  with  other 
standardization  efforts.  In  late  1983,  the  EAS  met  with  the  Institute  for  Interconnecting  and  Packaging  Electronic 
Circuits  (IPC)  in  an  attempt  to  coordinate  efforts.  It  was  decided  then  that  IPC  would  continue  to  focus  on  the  CAD 
to  CAM  interface  and  the  IGES  EAS  would  focus  on  modeling  and  CAD  to  CAD  issues.  Members  of  the  EAS  also 
heard  of  attempts  by  a silicon  foundry  to  develop  an  interchange  format  for  Integrated  Circuit  (IC)  designs,  and 
many  wondered  if  that  effort  would  duplicate,  complement,  or  conflict  with  what  was  being  developed  for  IGES. 


5 Later  renamed  Electrical  Applications  Committee  (EAC). 
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5.1  HARMONIZATION  ACTIVITIES 

In  April  1984,  the  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  Standards  Coordinating  Committee  called 
a meeting  that  further  drew  the  IGES  Organization  into  a dialog  with  other  standards  efforts.  Of  particular  interest 
was  closer  coordination  between  IGES  and  the  relatively  new  Electronic  Design  Interchange  Format  (EDIF)  effort. 
The  EDIF  representative  declined  an  offer  of  joint  participation,  for  fear  that  standardization  activities  might  delay 
the  EDIF  development  schedule — a factor  that  has  continued  to  impede,  from  both  sides,  true  coordination  among 
related  standards  efforts.  Other  electrical  standards  represented  included  the  IEEE  Very  High  Speed  Integrated 
Circuit  (VHSIC)  Hardware  Description  Language  (VHDL)6,  the  Abbreviated  Test  Language  for  All  Systems 
(ATLAS),  and  the  Tester  Independent  Support  Software  System  (TISSS). 

At  about  the  same  time,  a representative  from  Westinghouse  began  reaching  out  to  other  related  standardization 
efforts  across  the  Atlantic  Ocean,  and  authored  several  related  papers  that  were  published  by  CAM-I.  He  developed 
contacts  that  led  to  discussions  between  the  IGES  EAS  and  the  International  Electrotechnical  Commission  (IEC) 
Technical  Committee  3,  Documentation  and  Graphical  Symbols  (TC3).  In  particular,  a representative  from  NBS 
along  with  other  IGES  officers  attended  a meeting  of  TC3  subcommittee  SC3B  in  Los  Angeles.  Working  Group  2 of 
SC3B  had  published  the  proposed  standard  on  Interchange  Technique  for  Documents  of  Electrotechnical  Systems 
(ITDOES).  This  later  facilitated  the  involvement  of  TC3  in  the  ISO/IEC  Joint  Working  Group  with  ISO 
TC184/SC4. 

Many  organizations,  including  ANSI,  and  numerous  individuals  tried  to  find  ways  to  increase  the  awareness  and 
cooperation  among  related  electrical  standardization  efforts  with  little  measurable  success.  Each  group  working  on 
some  aspect(s)  of  the  standardization  for  electrical  and  electronic  product  data  had  a set  of  volunteers,  their 
sponsors,  and  a clientele  to  whom  they  felt  they  owed  their  scheduled  deliverables.  For  the  most  part,  no  two  efforts 
were  initiated  with  the  same  goal,  but  rather  extended  into  overlapping  territory  in  response  to  the  needs  of  their 
users.  Furthermore,  some  of  the  sanctioning  standards  bodies  depended  in  some  part  for  revenue  from  the  sale  of 
standards  documents.  A certain  amount  of  jealousy  about  which  organization  might  seem  subservient  to  which  other 
organization  also  hampered  some  of  the  willingness  of  people  at  the  working  level  to  share  results  and  efforts.  The 
resulting  array  of  conflicting  and  overlapping  standards  prevented  the  market  from  supporting  any  cohesive  standard 
interchange  methodology,  and  left  much  of  the  burden  of  data  exchange  on  the  shoulders  of  manufacturers  who  used 
CAD  systems. 

In  February  1988,  ANSI/ASME  Y 14.26  (the  same  committee  that  standardized  IGES)  raised  the  concern  to  ANSI 
management  in  a letter  that  stated: 

“...we  are  concerned  that  there  are  concurrent  overlapping  standards  activities  that  are  not 
coordinated.  Of  particular  concern  are  the  Initial  Graphics  Exchange  Specification  (IGES) 
Electrical  Application  subset,  the  Electronic  Design  Interchange  Format  (EDIF),  the  Institute  for 
Interconnecting  and  Packaging  Electronic  Circuits  (IPC)  35X  series  of  specifications  and  the 
VHSIC  Hardware  Description  Language  (VHDL)... [22]” 

While  the  standards  cited  were  not  the  only  efforts  of  concern,  they  were  specifications  that  ANSI  itself  had 
authorized  and  that  the  government  called  out  in  their  Computer-Aided  Acquisition  and  Logistics  Support  (CALS) 
standards.  This  letter  led  to  a “Harmonization”  meeting  at  El  A Headquarters  in  May  1988.  CAM-fs  Electronics 
Automation  Program  (CAM-I  EAP)  manager  followed  by  offering  to  champion  the  effort.  Participants  included 
Boeing,  McDonnell  Douglas,  Allied  Signal,  Eastman  Kodak,  Hewlett-Packard,  Northrop,  The  Plessey  Company, 
Westinghouse,  and  NIST.  In  February  of  1989,  the  El  A issued  results  of  an  evaluation  report  entitled  “Harmonizing 
CALS  Product  Data  Description  Standards  [23].”  The  report  evaluated  each  of  the  four  ANSI  standards  against  58 
steps  of  the  design  process  across  four  levels  of  product  [24]: 

Component:  Items  that  are  usually  packaged  as  an  indivisible  unit,  to  be  assembled  on  a board  or 
substrate. 

Board:  An  assembly  of  components  on  a board  or  substrate. 

Box : An  assembly  of  one  or  more  boards  to  implement  a complex  function. 

System:  A functionally  complete  assembly  of  components,  boards,  and  boxes. 


6 Authorized  by  IEEE  Project  Authorization  Request  (PAR)  PI 076. 
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The  CALS/EIA  Report  found  “...far  more  overlap  than... anticipated....  EDIF  overlaps  one  or  more  other 
standards  78  times.”  The  Report  created  a matrix  showing  which  lifecycle  steps  were  captured  by  which  of  the  four 
ANSI  standards,  carved  out  a scope  for  each  standard  based  on  this  matrix,  and  declared  “harmonization”  effectively 
accomplished.  This  proposed  solution  was  rejected  by  industry,  as  noted  in  a subsequent  CAM-I  report  [25]  that 
criticized  the  report’s  conclusions.  An  industry  member  of  ANSI  Y 14.26  summed  up  industry's  viewpoint  in  a 
letter  to  ANSI  in  1989: 

“An  electronics  company  which  performs  all  the  steps  in  the  design  process... using  heterogeneous 
computer  systems,  work  stations,  and  factory  NC  [numerical  control]  machinery  and  robots  would 
have  to  support  all  four  standards....  At  worst,  this  could  mean  not  only  having  to  implement  the 
software  to  support  each  standard,  but  also  having  translators  between  each  pair....  Such  an 
approach  (if  it  were  feasible)  would  be  cumbersome,  error-prone,  time-consuming,  and  costly.” 

In  November  1989,  NIST  accepted  the  leadership  of  the  Harmonization  effort,  which  was  later  formalized  as  the 
Harmonization  of  Product  Data  Standards  (HPS)  organization  under  the  Industrial  Automation  Planning  Panel 
(IAPP)  of  ANSI.  The  HPS  established  three  councils  (to  which  NIST  continued  to  serve  as  the  Secretariat): 
Business  Needs  and  Planning,  Standards  Development  and  Coordination,  and  Tools  and  Technology.  McDonnell 
Douglas,  then  NIST,  led  the  Tools  and  Technology  Council. 

The  major  accomplishments  of  the  HPS  organization  were  to  propose  a methodology  and  a process  for  harmonizing 
the  four  ANSI  standards,  and  to  publish  the  first  version  of  a coordinated  information  model  as  ANSI/HPS-100 
“HPS  Information  Federated  Model  Descriptions.”  Figure  4 and  Table  1 show  the  strategy  that  HPS  followed  in 
hope  to  achieve  harmonization;  note  the  group’s  intent  to  standardize  the  “Consensus  Conceptual  Model”  within  the 
ISO  STEP  standard  [26], 


The  Operative  Means  to  Harmonization 


“ We  do  not  expect  to  harmonize  the  formats  which  the  EE  standards  have  defined;  but  we  do  expect  to 
harmonize  the  product  information  represented  by  these  formats.  ” Standards  Development  Coordinating  Council,  7/91 

Figure  4.  “The  Operative  Means  to  Harmonization” 


Milton  Piatok,  Boeing. 
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The  HPS  proposed  the  following  process  to  guide  harmonization,  which  reflects  the  group's  early  belief  that  the  four 
standards  would  eventually  be  completely  represented  within  STEP  [27]: 


Process 

Guidance  for  Harmonization 

Gather  Models 

Gather  verified  conceptual  models  for  the  subject  area  of  current  focus  from  each  of 
the  relevant  standards  organizations. 

Federate 

Every  element  is  added  to  the  federated  model  in  the  data  dictionary.  Elements  are 
classified.  Unique  identical  and  conflicting  coverage  is  identified.  Conflicts  are 
resolved  by  creating  generic  elements  that  each  conflicting  element  can  be  mapped 
to.  The  Federated  model  contains  each  conflicting  element  as  well  as  resolving 
elements. 

Test 

Define  mapping  between  standards  through  the  generic  portion  of  the  federated 
model.  Create  test  vehicles  (test  cases)  for  the  subject  area  of  interest  in  the  original 
standards  run  test: 

Sending  Federated  Generic  Federated  Receiving 

Standard  o Model  o Portion  of  <=>  Model  <=>  Standard 

Format  Federated  Model  Format 

Compare  before  and  after  files  of  test  vehicles  document  mappings. 

Harmonize 

Derive  harmonized  model  from  tested,  generic  portion  of  federated  model. 

Submit  for  Standardization 

Submit  portions  of  harmonized  model  as  candidate  application  reference  models 
(ARMs)  in  STEP  as  they  are  ready.  The  harmonized  model  may  also  be  submitted 
for  national  standardization.  Hold  public  review. 

Integrate  with  STEP 

The  portions  of  the  harmonized  model  submitted  for  standardization  within  STEP 
will  be  integrated  with  STEP  resource  models  in  accordance  with  STEP  procedure. 

Develop  APs,  CDIMs 

Develop  application  protocol  (AP)  and  context-driven  information  model  (CDIM) 
for  subject  area  of  interest.  The  AP  will  reference  the  mappings  between  the 
harmonized  model  and  each  standard.  Identify  information  voids  that  none  of  the 
standards  cover. 

Table  1 : The  Harmonization  Process  ( V 1 . 1 ) 

Both  the  information  model  and  the  guidelines  for  harmonization,  later  referred  to  as  the  “federation”  to  reflect  the 
individual  organizations’  priority  of  autonomy,  aided  the  groundwork  for  continuing  international  collaboration. 
The  HPS  was  moved  under  the  CIM  Standards  Board  of  ANSI  and  then  deactivated  as  leadership  in  the  area  was 
transferred  to  the  international  arena  under  IEC  Technical  Committee  (TC)  93.  Through  its  working  groups,  IEC 
TC93  continues  to  develop  a federated  model  to  aid  in  the  interoperation  among  electrical  information  exchange 
standards.  NIST  representatives  continue  to  play  an  active  leadership  role  within  IEC  TC93  to  build  supporting 
electrical  and  electronic  standards. 

5.2  IGES  ELECTRICAL  TRANSITION  TO  STEP 

Although  IGES  continues  to  be  deployed  in  industry,  STEP  is  intended  to  address  its  weaknesses  and  provide  the 
industry  with  a broader,  more  robust  standard.  To  help  interested  manufacturers  prepare  their  people  for  Computer 
Integrated  Manufacturing  using  STEP,  the  IGES  Electrical  Applications  Committee  (EAC)  coordinated  work  of  two 
successive  Cal  Poly  Task  Teams.  The  first  [28]  developed  an  information  model  of  electrical  connectivity,  the 
second  [29]  a model  of  layered  electrical  products,  such  as  a printed  circuit  board  (PCB).  The  latter  report  included 
a computer  diskette  containing  a demonstration  of  the  model's  implementation.  This  demonstration  was  given 
before  an  ISO  plenary  session  in  1988,  and  proved  the  viability  of  modeling  as  the  basis  for  real-time  database 
retrieval  as  well  as  information  exchange.  The  final  reports  of  both  teams  included  EXPRESS  models  which  were 
later  incorporated  in  the  "STEP  Tokyo  Draft"  [30]  in  1988.  These  Task  teams  were  sponsored  by  the  Air  Force 
together  with  several  aerospace  companies. 

A notable  monetary  and  morale  boost  came  from  the  Navy'  Command,  Control  & Ocean  Surveillance  Center, 
Research  Development  Test  & Evaluation  Division,  which  funded  research  to  greatly  increase  the  accuracy  of  the 
transfer  of  Hybrid  Microcircuit  Assemblies  (HMA)  design  information  to  manufacturing  using  IGES.  The  results  of 
this  project  were  published  as  the  Initial  Graphics  Exchange  Specification  Hybrid  Microcircuit  Application  Protocol 
[31].  Some  of  the  theory'  developed  by  the  Cal  Poly  Teams  for  STEP  was  also  used  to  develop  the  Application 
Reference  Model  for  the  HMA  application.  However  the  Application  Interpreted  Model  (AIM)  was  not  in 
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EXPRESS,  but  was  comprised  of  a collection  of  IGES  entity  objects.  This  AIM  benefited  greatly  from  a funded 
analysis  of  the  major  ECAD  systems'  data  structures  as  found  in  translator  software. 

As  the  IGES  HMA  was  being  reviewed  within  the  EAC,  work  had  begun  work  on  an  electrical  AP  within  the  STEP 
standard,  referred  to  as  AP  210.  In  recognition  of  industry’s  reliance  on  IGES  for  electrical  data  exchange,  and  the 
uncertain  schedule  whereby  STEP  AP  210  would  be  released,  the  EAC  resolved*  to  standardize  an  IGES  Layered 
Electrical  Product  (LEP)  AP  based  on  the  HMA  work.  This  effort  was  initially  led  by  the  Department  of  Energy's 
Sandia  National  Laboratories  and  later  by  NIST* 9,  and  represented  the  cumulative  effort  of  over  a decade  of  work  by 
scores  of  volunteers.  The  EAC  strived  to  serve  as  a collaboration  point,  so  that  the  evolving  IGES  LEP  AP  and  the 
STEP  AP  210  [32]  could  share  a common  technical  foundation.  The  LEP  AP  referenced  IGES  Version  5.3  [33], 
and  drew  its  name  from  the  model  contained  in  the  Cal  Poly  Task  Team  Extension  Final  Report. 

6.  THE  IGES  LEGACY 

Even  before  the  ANSI/HPS-100  model  emerged,  the  early  efforts  of  the  IGES  Electrical  Committee  provided  some 
valuable  general  lessons  learned  about  information  modeling  in  a standard's  setting: 

• Team  diversity.  Need  varied  backgrounds  (programmers,  DBMS,  subject  matter  experts,  suppliers,  customers, 
testers,  a facilitator,  scribes  and  visionaries) 

• Committee  resources.  Need  stable  work  force  (of  6 to  12  people)  having  committed  resources. 

• Trained  team.  Need  trained  participants;  otherwise,  frequent  methodology  training  (for  newcomers)  slows 
development. 

• Strong  leadership.  Need  knowledgeable  oversight. 

• Long-term  commitment.  Need  long  term  commitment  from  management. 

• Active  communication.  Need  frequent  and  timely  communication  within  the  team. 

• Strong  public  relations.  Need  public  awareness  of  intent,  schedule,  and  scope  of  effort. 

• Information  modeling.  Information  modeling  is  not  easy,  but  it  seems  necessary,  though  not  sufficient,  for 
Computer  Integrated  Manufacturing  (CIM). 

The  development  of  IGES  showed  that  Standards  can  be  produced  quickly  when  the  climate  is  ripe.  What  makes  a 
“ripe”  climate? 

• The  standard  has  a very  limited  scope. 

• A short  contractual  deadline  exists. 

• The  playing  field  for  consensus-building  is  relatively  small — only  a few'  CAD  vendors  in  existence  and  only  a 
few  users  applying  CAD  technologies. 

• A high  level  of  dedicated  buy-in  exists. 

The  technical  legacy  from  IGES  alone  was  plentiful  for  the  next  generation  of  product  data  standards: 

• Requirements  must  be  documented. 

• Subsets  are  inadequate  and  application  protocols  are  needed  [34][35][36]. 

• Product  data  exchange  standards  need  to  have  enhanced  functional  capabilities,  including: 

• Context  and  viewpoint  (presentation  does  not  equal  meaning). 

• Unambiguous  semantics. 

• Three-dimensional  (3D)  solid  model  exchange  (for  mechanical  parts). 

• 3D  tolerancing  and  dimensioning. 

• Assessing  compliance  to  the  standard  is  necessary. 

• A migration  path  for  legacy  systems  is  a must. 


In  the  EAC's  "Mesa  Resolution"  of  January  1994. 

9 Under  Larry  O'Connell  of  Sandia,  and  then  Curtis  Parks  of  NIST. 
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7.  SUMMARY 


The  technical  development  of  IGES,  related  non-US  standards,  the  harmonization  initiative,  and  the  development  of 
STEP  are  inseparable  from  the  development  of  the  relationships  among  the  contributors.  There  was  tremendous 
excitement  among  the  early  developers  about  embarking  on  new  territory.  Passions  ran  high.  Vendors  learned  early 
that  by  opening  up  their  systems  to  the  public  they  could  more  readily  catch  a market — not  lose  it.  Late-night 
conversations  in  smoke-filled  rooms  played  a critical  role  in  the  birth  of  these  early  standards,  as  did  personal  trust 
among  the  participants.  Once  feasibility  was  shown  through  these  early  exchange  standards,  the  tremendous  need 
within  industry  for  a formally  standardized  CAD  exchange  capability  drove  the  world  to  development  efforts  such 
as  STEP.  These  early  pioneers  had  little  idea  of  the  magnitude  and  longevity'  of  the  efforts  that  would  follow  their 
lead. 


iistorical  Overview 


Figure  5.  “Historical  Overview.’ 


. 
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